This section provides background information related to the present disclosure which is not necessarily prior art.
Many devices today utilize a processor or microprocessor that executes core software. Further, the architectures of these processors or microprocessors may be open to programmers to develop applications for the device. For instance, third party developers or in-house developers may design applications for the telematics device. In order to facilitate the widespread designing of applications to execute on the processor, the processor manufacturer can develop an application programmers interface (API) for the developers to interface between the application and the processor. An API is a set of rules and specifications that a developer uses to access and make use of the services and resources of the operating system executing on the processor. Thus, an API can serve as an interface between a first software application and a second software application. For example, an API allows a programmer to develop an application that may execute on an operating system of a telematics device. The developer of the application need not know the particular system calls for the particular processor used in the telematics device or the operating system executing thereon. Rather, an API having standardized rules and specifications independent of the processor or operating system allows the programmer to use the syntax and rules of the API, such that the API provides a layer of abstraction from the lower level software and/or hardware components of the device.
Traditionally, the applications intended for a device were statically linked with the link libraries and files of the API. That is, the applications were linked at compile time. As API designers now increasingly desire to expand and modify the link libraries, operating systems of devices are starting in dynamically link the applications to the linked libraries of the API. For example, the Binary Runtime Environment for Wireless (BREW) is an API developed by Qualcomm that allows developers to develop applications for mobile devices. Historically, BREW was statically linked, but the most recent BREW APIs require dynamic linking of BREW applications. In order to run a dynamically linked BREW application, there are a number of complicated processes that are executed prior to executing the BREW application. The execution of these complicated processes increases a risk that the BREW application will not execute. Thus, an issue that arises is a dynamically linked environment is that the dynamic linking of applications increases the risk that the application will not to start, as opposed to such a likelihood in a statically linked environment. Thus, there is a need to increase the reliability of dynamically linked applications.
Further areas of applicability will become apparent from the description provided herein. The description and specific examples in this summary are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.